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Detailed Action 
Claim Objections 

1. Claims 1, 14-17, 26, 33, 38-39 are objected to because of the following informalities: 
In line 1 1, claim 1, remove the term "acts." 

In line 1, claim 14, replace "claim 1" with "claim 13." 
In line 1, claim 15, replace "claim 1" with "claim 14." 
In line 1, claim 16, replace "claim 1" with "claim 13 " 
In line 1, claim 17, replace "claim 1" with "claim 13 " 
In line 2, claim 33, append "s" in the word "own." 
In line 2, claim 38, add a " " at the end of the claim. 
In line 1, claim 39, replace "claim 39" with "claim 26." 
Appropriate correction is required. 

Claim Rejections - 35 USC § 112 
The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

2. Claims 1, 13, 26, 33 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. 

Claim 1 recites the limitation "the computed value" in line 5 of the claim. There is 
insufficient antecedent basis for this limitation in the claim. It is unclear as to what this 
limitation refers to. 
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Claim 1 recites the limitation "the input data functions" in line 8 of the claim. There is 
insufficient antecedent basis for this limitation in the claim. It is unclear as to what this 
limitation refers to. 

Claim 1 recites the limitation "functional units" in line 12 of the claim. There is 
insufficient antecedent basis for this limitation in the claim. It is unclear as to what this 
limitation refers to. 

Claim 13 recites the limitation "the functional units" in line 9 of the claim. There is 
insufficient antecedent basis for this limitation in the claim. It is unclear as to what this 
limitation refers to. 

Claim 13 recites the limitation "the computed value" in line 12 of the claim. There is 
insufficient antecedent basis for this limitation in the claim. It is unclear as to what this 
limitation refers to. 

Claim 26 recites the limitation "the hosting cluster" in line 6 of the claim. There is 
insufficient antecedent basis for this limitation in the claim. It is unclear as to what this 
limitation refers to. 

Claim 33 recites the limitation "one of two components" in line 2 of the claim. There is 
insufficient antecedent basis for this limitation in the claim. It is unclear as to what this 
limitation refers to. 
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Claim Rejections - 35 USC § 102 
The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 

3. Claims 1-7, 9-12, 13-19, 21-25, 26-36, 38-39 are rejected under 35 U.S.C. 102(e) as 
being anticipated by Zisapel et al. (USP 6,249,801). 

Regarding claim 1, Zisapel discloses a context-selection mechanism for selecting a best 
context (selecting a best server farm site to which requests from a particular subnet should be 
routed, see col. 6, lines 30-49) from a pool of contexts (from a pool of Load Balancers LB1, LB2 
and LB3) for processing a data packet (for processing HTTP or FTP request via the Internet, see 
col. 5, lines 29-43) comprising: 

an interface (proximity table, see element 54, Fig. 2A and col. 6, lines 30-39) for 
communicating with a multi-streaming processor (load balancer LB 1 /server farm, see col. 6, 
lines 29-43 and Fig. 2A); 

circuitry for computing input data into a result value according to logic rule (a total 
weighted value for each server farm is computed based on the latency, hopes between client and 
each server farm and the processing capacity and quality of each server farm site, see col. 6, lines 
40-67 and col. 7, lines 1-35) and for selecting a context based on the computed value (for 
selecting the "closest" server farm site to client, see col. 7, lines 1-35); and 
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a loading mechanism for preloading the packet information (closest site subnet 
information, see col. 7, lines 1-52) into the selected context for subsequent processing (the 
closest site is stored in the proximity table by LB1, see col. 7, lines 1-35); 

characterized in that the computation of the input data functions (computing the latency, 
hopes between client and each server farm and the processing capacity and quality of each server 
farm site, see col. 6, lines 40-67 and col. 7, lines 1-35) to enable identification and selection of a 
best context for processing a data packet according to the logic rule at the instant time (determine 
the lowest total weighted value and selects the server farm site that is "closest" to client for 
client requests, see col. 6, lines 30-49 and col. 7, lines 1-52) such that a multitude of subsequent 
context selections over a period of time (the best network proximity to a particular subnet for 
client is periodically determined, see col. 7, lines 36-52) to balance load pressure on functional 
units housed within the multi-streaming processor and required for packet processing (in 
subsequent server farm site selections, incoming requests from client is forwarded by the load 
balancer to a location that does not have the best network proximity should a load report received 
from the best location indicate that the location is too busy to receive requests, see col. 7, lines 
36-52). 

Regarding claim 2, Zisapel discloses the context-selection mechanism of claim 1 
integrated to a data packet router (load balancer, see Fig. 2A) operating in a data-packet-network 
(the Internet, see Fig. 2A). 
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Regarding claim 3, Zisapel discloses the context-selection mechanism of claim 2 wherein 
the data-packet- network is the Internet network (the Internet, see col. 5, lines 8-28 and Fig. 2A). 

Regarding claim 4, Zisapel discloses the context-selection mechanism of claim 1 wherein 
the pool of contexts (server status tables of server farm sites, see col. 5, lines 8-28) is divided 
into separate clusters (server farm sites) in the processing unit (load balancer/server farm site, see 
Fig. 2A), each cluster (each server farm site) containing some of the functional units used in 
packet processing (contains servers to process client requests, see col. 5, lines 8-28). 

Regarding claim 5, Zisapel discloses the context-selection mechanism of claim 1 wherein 
the input data into the computation circuitry includes availability information of individual ones 
of the pool of contexts at the time of computation (server farm availability, see col. 5, lines 8-28 
and col. 7, lines 1-35), 

Regarding claim 6, Zisapel discloses the context-selection mechanism of claim 5 wherein 
the input data into the computation circuitry further includes real time information of 
any processing streams stalled in un-available ones of the pool of contexts (location to serve 
client requests at the best proximity network is unavailable) and the reason for the stall (too busy 
to receive requests, see col. 7, lines 36-52). 

Regarding claim 7, Zisapel discloses the context-selection mechanism of claim 5 wherein 
the input data into the computation circuitry further includes statistical data about 
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previous processing time periods required to process similar data packets (latency of the 
transmission, see col. 7, lines 17-35). 

Regarding claim 9, Zisapel discloses the context-selection mechanism of claim 1 wherein 
the input data is sourced from the multi-streaming processor (overall status and load statistics are 
maintained at each load balancer, see col. 5, lines 8-28). 

Regarding claim 10, Zisapel discloses the context-selection mechanism of claim 1 
wherein the input data is sourced from a third party (overall status and load statistics at a load 
balancer are received from load balancers, see col. 5, lines 8-43). 

Regarding claim 11, Zisapel discloses the context-selection mechanism of claim 4 
wherein the clusters are numbered (Load Balances LB1, LB2, LB3, see Fig, 2A) and the 
functional units are distributed symmetrically therein (one balancer is connected to one server 
while another balancer is also connected to one server, see col. 5, lines 8-28). 

Regarding claim 12, Zisapel discloses the context-selection mechanism of claim 4 
wherein the clusters are numbered (Load Balances LB1, LB2, LB3, see Fig, 2A) and the 
functional units are distributed asymmetrically therein (one balancer is connected to one server 
while another balancer is connected to more than one servers, see col. 5, lines 8-28). 
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Regarding claim 13, Zisapel discloses a system for load balancing pressure on functional 
units (load balancing for servers in each server farm site) within a multi- streaming processor 
(load balancer) during the processing of multiple data packets comprising: 

a context-selection mechanism a context-selection mechanism for selecting a best context 
(selecting a best server farm site to which requests from a particular subnet should be routed, see 
col. 6, lines 30-49) having a communication interface (proximity table, see element 54, Fig. 2A 
and col. 6, lines 30-39), circuitry for computing input data according to a logic rule (a total 
weighted value for each server farm is computed based on the latency, hopes between client and 
each server farm and the processing capacity and quality of each server farm site, see col. 6, lines 
40-67 and col 7, lines 1-35) and a mechanism for preloading packet information into available 
ones of a pool of contexts (the closest site is stored in the proximity table by LB1, see col. 7, 
lines 1-35); 

a multi-streaming processor responsible for processing the data packets (load balancer for 
processing FTP or HTTP request from client via the Internet, see col. 5, lines 8-43), the 
processor hosting the functional units (load balancer LB1 hosting the servers its server farm site) 
and the context pool (holding server status information of other load balancers, see col. 5, lines 
8-28); and 

a set of instructions comprising the logic rule governing context selection (computing the 
latency, hopes between client and each server farm and the processing capacity and quality of 
each server farm site, see col. 6, lines 40-67 and col. 7, lines 1-35), wherein pressure upon the 
functional units within the processor core is balanced by selecting individual contexts according 
to the computed value following the set of instructions (in subsequent server farm site selections, 
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incoming requests from client is forwarded by the load balancer to a location that does not have 
the best network proximity should a load report received from the best location indicate that the 
location is too busy to receive requests, see col. 7, lines 36-52). 

Regarding claim 14, Zisapel discloses the system of claim 1 integrated to a data 
packet router (load balancer, see Fig. 2A) operating in a data-packet-network (the Internet, see 
Fig. 2A). 

Regarding claim 15, Zisapel discloses the system of claim 2 wherein the data-packet- 
network is the Internet network (the Internet, see col. 5, lines 8-28 and Fig. 2A). 

Regarding claim 16, Zisapel discloses the system of claim 1 wherein the pool of 
contexts (server status tables of server farm sites, see col. 5, lines 8-28) is divided into separate 
clusters (server farm sites) in the processing unit (load balancer/server farm site, see Fig. 2A), 
each cluster (each server farm site) containing some of the functional units used in packet 
processing (contains servers to process client requests, see col. 5, lines 8-28). 

Regarding claim 17, Zisapel discloses the system of claim 1 wherein the input data into 
the computation circuitry includes availability information of individual ones of the pool 
of contexts at the time of computation (server farm availability, see col. 5, lines 8-28 and col. 7, 
lines 1-35). 
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Regarding claim 18, Zisapel discloses the system of claim 13 wherein the input data into 
the computation circuitry further includes real time information of any processing streams stalled 
in un-available ones of the pool of contexts (location to serve client requests at the best proximity 
network is unavailable) and the reason for the stall (too busy to receive requests, see col. 7, lines 
36-52). 

Regarding claim 19, Zisapel discloses the system of claim 13 wherein the input data into 
the computation circuitry further includes statistical data about previous processing time periods 
required to process similar data packets (latency of the transmission, see col. 7, lines 17-35). 

Regarding claim 21, Zisapel discloses the system of claim 13 wherein the input data is 
sourced from the multi- streaming processor (overall status and load statistics are maintained at 
each load balancer, see col. 5, lines 8-28) and provided in a software table (proximity table, see 
col. 6, lines 30-39, col. 7, lines 62-65). 

Regarding claim 22, Zisapel discloses the system of claim 13 wherein the input data is 
sourced from a third party (overall status and load statistics at a load balancer are received from 
load balancers, see col, 5, lines 8-43). 

Regarding claim 23, Zisapel discloses the system of claim 16 wherein the clusters are 
numbered (Load Balances LB1, LB2, LB3, see Fig, 2A) and the functional units are distributed 
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symmetrically therein (one balancer is connected to one server while another balancer is also 
connected to one server, see col. 5, lines 8-28). 

Regarding claim 24, Zisapel discloses the system of claim 16 wherein the clusters are 
numbered (Load Balances LB1, LB2, LB3, see Fig, 2A) and the functional units are distributed 
asymmetrically therein (one balancer is connected to one server while another balancer is 
connected to more than one servers, see col. 5, lines 8-28). 

Regarding claim 25, Zisapel discloses the system of claim 13 wherein the set of 
instructions comprising the logic rule is programmable (see col. 7, lines 17-65). 

Regarding claim 26, Zisapel discloses a method for load balancing pressure on functional 
units (servers) contained within a multi- streaming processor core (load balancer/server farm site, 
see Fig. 2A and col. 5, lines 8-28) during processing of multiple data packets (when processing 
FTP or HTTP requests) comprising steps of: 

(a) arranging the functional units (servers SI to Sn) into more than one separate 
cluster (server farm sites, see col. 5, lines 8-28 and Fig. 2A) on the core of the processor, each 
cluster (each server farm site) containing an equal number of contexts (each server farm site 
contains a server status table) that may write to the functional units within the hosting cluster 
(Load Balancers LB2 may write overall status and load statistics to Load Balancer LB1, see col. 
5, lines 8-28); 
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(b) receiving a data packet for processing (receiving FTP or HTTP request, see col. 5, 
lines 8-28); 

(c) receiving as input for computation, data about the instant availability status of 
individual contexts within each cluster (receiving availability status of other load balancers, see 
col. 5, lines 8-28); 

(d) receiving as input for computation, data about stream status of streams occupying any 
contexts within each cluster (receiving current load status of other load balancers, see col. 5, 
lines 8-28); and 

(e) computing the data received as input to produce a value (computing the latency of the 
transmission to determined a total weighted value of each server farm is determined), the value 
identifying and initiating selection of a best context for processing the data packet (the lowest 
total weighted value of all polling will be identified as the closest proximity network to client, 
see col. 7, lines 17-52) and balancing the load of the functional units within each cluster 
(incoming request will then be routed to a location having the best network proximity to client 
and thus balancing the load of other server farm sites that do not have the best network proximity 
to client, see col. 7, lines 17-52); and 

(f) repeating steps (b) through (e) for each of the multiple data packets for processing 
(determining the best proximity network after a predetermined amount of time has elapsed, see 
col. 7, lines 35-52). 
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Regarding claim 27, Zisapel discloses the method of claim 26 practiced in conjunction 
with a data packet router (load balancer, see Fig. 2A) operating in a data-packet-network (the 
Internet, see Fig. 2A). 

Regarding claim 28, Zisapel discloses the method of claim 27 wherein the data-packet- 
network is the Internet network (the Internet, see col. 5, lines 8-28 and Fig. 2A). 

Regarding claim 29, Zisapel discloses the method of claim 26 wherein in step (a) the 
functional units are provided within each cluster in a symmetrical fashion (one balancer is 
connected to one server while another balancer is also connected to one server, see col. 5, lines 
8-28). 

Regarding claim 30, Zisapel discloses the method of claim 26 wherein in step (a) the 
functional units are provided within each cluster in an asymmetrical fashion (one balancer is 
connected to one server while another balancer is connected to more than one servers, see col. 5, 
lines 8-28). 

Regarding claim 31, Zisapel discloses the method of claim 26 wherein in step (b) the 
packet is received at a data port of a data router and requires automatic activation (polling 
response is received at Load Balancer LB1 whose virtual IP address is 100.100. 1.0, see col. 5, 
lines 28-38). 
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Regarding claim 32, Zisapel discloses the method of claim 26 wherein in step (b) the 
packet is held by the processor and requires a context for processing (the polling response are 
held at LB1 and compared with the polling results received from LB2 and LB3 to determine 
weighted value for each server farm, see col. 7, lines 18-35). 

Regarding claim 33, Zisapel discloses the method of claim 26 wherein in step (c) 
availability status comprises an indication of which one of two components owns each context 
(LB1 and LB2 know each other's availability, see col. 5, lines 8-28). 

Regarding claim 34, Zisapel discloses the method of claim 33 wherein in step (c) one of 
the components is the processor (LB1) and other component is a packet management unit (LB2, 
see col. 5, lines 8-28). 

Regarding claim 35, Zisapel discloses the method of claim 26 wherein in step (d) the data 
about stream status includes whether or not streams are stalled within any of the contexts 
(location to serve client requests at the best proximity network is unavailable) and the reason for 
each instance of a stalled stream (too busy to receive requests, see col. 7, lines 36-52). 

Regarding claim 36, Zisapel discloses the method of claim 26 wherein in step (d) the data 
about stream status includes time parameters of how long each stream will take to process 
data packets associated with their contexts (latency of the transmission, see col. 7, lines 17-35). 



Application/Control Number: 09/881 ,628 Page 15 

Art Unit: 2664 

Regarding claim 38, Zisapel discloses the method of claim 26 wherein in steps (c) 
through (d) are practiced according to a set of rules of logic (see col, 7, lines 17-35). 

Regarding claim 39, Zisapel discloses the method of claim 39 wherein the rule of logic is 
programmable (see col. 7, lines 17-65). 

Claim Rejections - 35 USC § 103 
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. Claims 8, 20, 37 are rejected under 35 U.S.C. 103(a) as being unpatentable over Zisapel 
et al. 

Regarding claim 8, Zisapel discloses all the aspects of the claimed invention set forth in 
the rejection of claim 5 above, except fails to explicitly show the context-selection mechanism of 
claim 5 wherein the input data into the computation circuitry further includes statistical data 
about the distribution of instruction types associated with individual ones of previously 
processed and similar data packets. However, Zisapel discloses the request type from client can 
be DNS request or HTTP request (see col. 7, lines 52-61). Therefore, it would have been 
obvious to one of ordinary skill in the art at the time the invention was made to modify the load 
balancing method and system of Zisapel with the teaching of rerouting requests based on the 
type of request made by client such that the weighted value to determine which load balancer 
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will be the best proximity network to respond to client's request is based on the distribution of 
what request type to be instructed by client. The motivation to do so is to enable redirecting the 
request to the appropriate location according to the type of request made by client during the 
determination of the best proximity network to client 

Regarding claim 20, Zisapel discloses all the aspects of the claimed invention set forth in 
the rejection of claim 5 above, except fails to explicitly show the system of claim 13 wherein the 
input data into the computation circuitry further includes statistical data about the distribution of 
instruction types associated with individual ones of previously processed and similar data 
packets. However, Zisapel discloses the request type from client can be DNS request or HTTP 
request (see col. 7, lines 52-61). Therefore, it would have been obvious to one of ordinary skill 
in the art at the time the invention was made to modify the load balancing method and system of 
Zisapel with the teaching of rerouting requests based on the type of request made by client such 
that the weighted value to determine which load balancer will be the best proximity network to 
respond to client's request is based on the distribution of what request type to be instructed by 
client. The motivation to do so is to enable redirecting the request to the appropriate location 
according to the type of request made by client during the determination of the best proximity 
network to client 

Regarding claim 37, Zisapel discloses all the aspects of the claimed invention set forth in 
the rejection of claim 5 above, except fails to explicitly show the method of claim 26 wherein in 
step (d) the data about stream status includes distribution parameters of instruction types that 
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each stream has executed to process its data packet. However, Zisapel discloses the request type 
from client can be DNS request or HTTP request (see col. 7, lines 52-61). Therefore, it would 
have been obvious to one of ordinary skill in the art at the time the invention was made to 
modify the load balancing method and system of Zisapel with the teaching of rerouting requests 
based on the type of request made by client such that the weighted value to determine which load 
balancer will be the best proximity network to respond to client's request is based on the 
distribution of what request type to be instructed by client. The motivation to do so is to enable 
redirecting the request to the appropriate location according to the type of request made by client 
during the determination of the best proximity network to client. 



Conclusion 

5. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

US Publication 2004/0 1 483 82 to Narad et al. 
US Publication 2005/0063401 to Kenner et al. 
US Publication 2004/0 1 7247 1 to Porter 
US Publication 2002/0124262 to Basso et al. 
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6. 



Any inquiry concerning this communication or earlier communications from the 



examiner should be directed to Kevin Mew whose telephone number is 571-272-3 141 . The 
examiner can normally be reached on 9:00 am - 5:30 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Wellington Chin can be reached on 571-272-3 134. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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